以前在新創運作 scrum 時，好像覺得在專案中導入敏捷是一件再自然而然不過的事情，後來慢慢才明白原來我一直以來把他當成一種工作法，後來才發現敏捷其實是一種文化，只是這種文化跟新創氛圍比較契合，但在其他公司導入敏捷可能掀起一整個組織的變革。

例如像在金融業或是電信業這種受到政府法規高度控管的行業，可能在一些在一般公司可以快速執行的事項，都需要層層檢核，所有兩個禮拜的 sprint 可能在流程上就卡了三個月或半年以上。

那這樣的組織就與敏捷無緣了嗎？其實還是有一些破口可以突破！今天跟大家談談大公司或較傳統的組織如何導入敏捷的一些小小觀察。

1. 小單位試行

如果短時間內就希望公司改變幾十年的工作流程，那失敗是可以預期的，除了可能會引起極大的反彈，而且大規模的變動對大公司來說也要承擔較大的風險；所以不妨先挑選其中的小單位開始試行，在這個單位內的專案沒有到必要跑特定的流程，通常可以從大公司產品部門的子產品線或是影響範圍較小的產品團隊開始試跑，若是一個大的產品team，則可以選擇小專案開始嘗試。

2. 由上到下

通常敏捷代表這個團隊階層化不明顯，大家用任務制的方式完成，所以通常會認為敏捷是由下到上產生變化；但在龐大的組織裡，階層幾乎不可能消除，因為這是他們管理上必須的一部分，所以我反而會覺得在這樣的情況下敏捷應該由上而下推動，也就是上層必須具備敏捷思維，而向下傳達讓底下的人從這種思維找出作法，或是可以讓中階主管取得上層同意，再向下帶領團隊運行，才不會逕自的開始後，傳到上層耳裡便胎死腹中，或是因為沒有上層的令旗，底下的士兵也不會鳥你。

3. 用刪去法

如果剛開始就想著要把整套敏捷的邏輯或作法搬過來，那會很難推動，比較簡單的做法是 debug ，先找出再組織中或工作流程中有什麼阻礙以及不合理不效率的地方，再漸進式的排除！

如果你也是在大公司大組織下的一員，不妨思考一下，目前公司有沒有哪個部分正在向敏捷前行？如果沒有的話，你覺得最有可能從哪個部分開始推動？